…for break_ok/continue_ok

Add target features for sm_* and ptx*, both of which form a partial
order, but cannot be combined to a single partial order. These mirror
the LLVM target features, but we do not provide LLVM target
processors (which imply both an sm_* and ptx* feature).

Add some documentation for the nvptx target.

Normally LLVM and rustc agree about what features are implied by
target-cpu, but for NVPTX, LLVM considers sm_* and ptx* features to be
exclusive, which makes sense for codegen purposes. But in Rust, we want
to think of them as:

  sm_{sver} means that the target supports the hardware features of sver

  ptx{pver} means the driver supports PTX ISA pver

Intrinsics usually require a minimum sm_{sver} and ptx{pver}.

Prior to this commit, -Ctarget-cpu=sm_70 would activate only sm_70 and
ptx60 (the minimum PTX version that supports sm_70, which maximizes
driver compatibility). With this commit, it also activates all the
implied target features (sm_20, ..., sm_62; ptx32, ..., ptx50).

This avoids scheduling drops and immediately unscheduling them. Drops
for guard bindings/temporaries are still scheduled and unscheduled as
before.

Co-authored-by: Tshepang Mbambo <[email protected]>

…or indexing into a function table as described by RFC 3407

Related to rust-lang#131229 (comment).

Make suggestions to remove params and super traits tool-only, and make
the suggestion span more accurate.

```
error[E0567]: auto traits cannot have generic parameters
  --> $DIR/auto-trait-validation.rs:6:19
   |
LL | auto trait Generic<T> {}
   |            -------^^^
   |            |
   |            auto trait cannot have generic parameters

error[E0568]: auto traits cannot have super traits or lifetime bounds
  --> $DIR/auto-trait-validation.rs:8:20
   |
LL | auto trait Bound : Copy {}
   |            -----   ^^^^
   |            |
   |            auto traits cannot have super traits or lifetime bounds
```

```
error[E0380]: auto traits cannot have associated items
  --> $DIR/issue-23080.rs:5:8
   |
LL | unsafe auto trait Trait {
   |                   ----- auto traits cannot have associated items
LL |     fn method(&self) {
   |        ^^^^^^
```

…r-errors

Tweak auto trait errors

Make suggestions to remove params and super traits verbose and make spans more accurate.

```
error[E0567]: auto traits cannot have generic parameters
  --> $DIR/auto-trait-validation.rs:6:19
   |
LL | auto trait Generic<T> {}
   |            -------^^^
   |            |
   |            auto trait cannot have generic parameters

error[E0568]: auto traits cannot have super traits or lifetime bounds
  --> $DIR/auto-trait-validation.rs:8:20
   |
LL | auto trait Bound : Copy {}
   |            -----   ^^^^
   |            |
   |            auto traits cannot have super traits or lifetime bounds
```

```
error[E0380]: auto traits cannot have associated items
  --> $DIR/issue-23080.rs:5:8
   |
LL | unsafe auto trait Trait {
   |                   ----- auto traits cannot have associated items
LL |     fn method(&self) {
   |        ^^^^^^
```

… r=ZuseZ4

add nvptx_target_feature

Tracking issue: rust-lang#141468 (nvptx), which is part of rust-lang#44839 (catch-all arches)
The feature gate is `#![feature(nvptx_target_feature)]`

This exposes the target features `sm_20` through `sm_120a` [as defined](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.1/llvm/lib/Target/NVPTX/NVPTX.td#L59-L85) by LLVM.

Cc: `@gonzalobg`
`@rustbot` label +O-NVPTX +A-target-feature

implement continue_ok and break_ok for ControlFlow

Tracking issue: rust-lang#140266

r? `@dtolnay`

… r=Nadrieril,traviscross

lower pattern bindings in the order they're written and base drop order on primary bindings' order

To fix rust-lang#142163, this PR does two things:
- Makes match arms base their drop order on the first sub-branch instead of the last sub-branch. Together with the second change, this makes bindings' drop order correspond to the relative order of when each binding first appears (i.e. the order of the "primary" bindings).
- Lowers pattern bindings in the order they're written (still treating the right-hand side of a ``@`` as coming before the binding on the left). In each sub-branch of a match arm, this is the order that would be obtained if the or-alternatives chosen in that sub-branch were inlined into the arm's pattern. This both affects drop order (making bindings in or-patterns not be dropped first) and fixes the issue in [this test](https://github.com/rust-lang/rust/blob/2a023bf80a6fbd6a06d5460a34eb247b986286ed/tests/ui/pattern/bindings-after-at/bind-by-copy-or-pat.rs) from rust-lang#121716.

My approach to the second point is admittedly a bit trickier than may be necessary. To avoid passing around a counter when building `FlatPat`s, I've instead added just enough information to recover the original structure of the pattern's bindings from a `MatchTreeSubBranch`'s path through the `Candidate` tree. Some alternatives:
- We could use a counter, then sort bindings by their ordinals when making `MatchTreeSubBranch`es.
- I'd like to experiment with always merging sub-candidates and removing `test_remaining_match_pairs_after_or`; that would require lowering bindings and guards in a different way. That makes it a bigger change too, though, so I figure it might be simplest to start here.
- For a very big change, we could track which or-alternatives succeed at runtime to base drop order on the binding order in the particular alternatives matched.

This is a breaking change. It will need a crater run, language team sign-off, and likely updates to the Reference.

This will conflict with rust-lang#143376 and probably also rust-lang#143028, so they shouldn't be merged at the same time.

r? `@matthewjasper` or `@Nadrieril`

…zelmann

Port #[macro_export] to the new attribute parsing infrastructure

Ports macro_export to the new attribute parsing infrastructure for rust-lang#131229 (comment)

r? `@oli-obk`

cc `@JonathanBrouwer` `@jdonszelmann`

…ffleLapkin

Additional tce tests

r? ``@oli-obk``

Adds known-bug tests for LLVM emissions regarding indirect operands for TCE. Also includes a test, `indexer.rs`, referring to function_table behavior described by the RFC.

Depends on rust-lang#144232

Closes rust-lang#144293

…oxyUwU

Add documentation for unstable_feature_bound

There is more detail and explanation in https://hackmd.io/``@tiif/Byd3mq7Ige``

Original PR that implemented this: rust-lang#140399

r? ``@BoxyUwU`` to nominate for types team discussion

…szelmann

Port `#[coroutine]` to the new attribute system

Related to rust-lang#131229 (comment).

r? ``@jdonszelmann``

…er, r=WaffleLapkin

Anonymize binders in tail call sig

See the comment for explanation

Fixes rust-lang#144826

r? WaffleLapkin